Columbia Kermit/kermit.zip/newsgroups/misc.20030409-20031118/[e-mail]_Thu May 1 14:19:30 EDT 2003.msg

Text File | 2020-01-01 | 6KB | 133 lines

Article: 14254 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!panix!newsfeed!news.maxwell.syr.edu!feed.uncensored-news.com!ord-feed.news.verio.net!stl-feed.news.verio.net!news.cpicorp.com!not-for-mail
From: Derek Chen-Becker <[e-mail]>
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Changed behavior of receive/transmit move-to
Date: Thu, 01 May 2003 12:56:13 -0500
Organization: CPI Corporation
Lines: 108
Message-ID: <b8rn1f$d5i$[e-mail]>
References: <b8rfll$kfv$[e-mail]> <b8rkdi$mo0$[e-mail]>
NNTP-Posting-Host: dbecker-ld.cpicorp.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: cpimail.cpicorp.com 1051811695 13490 131.100.250.5 (1 May 2003 17:54:55 GMT)
X-Complaints-To: [e-mail]
NNTP-Posting-Date: Thu, 1 May 2003 17:54:55 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
In-Reply-To: <b8rkdi$mo0$[e-mail]>
X-Enigmail-Version: 0.71.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14254

Thanks for the info. I understand your concerns with deferring
evaluation of the path. I think deferring does make the option much more
flexible (especially the way we're using it :) ). Perhaps a flag that
controls whether the evaluation is performed immediately or deferred
would allow for a more consistent usage. In the meantime we'll move back
to 8.206.

Thanks,

Derek

Frank da Cruz wrote:
> In article <b8rfll$kfv$[e-mail]>,
> Derek Chen-Becker  <[e-mail]> wrote:
> :      The behavior of the set receive move-to command seems to have
> : changed between c-kermit 8.206 and 8.209. It used to resolve the full
> : path of the move-to target upon each transfer, and now it appears to
> : resolve it on login through IKSD. We have a directory structure like this:
> :
> : ~/
> : ~/a
> : ~/a/incoming
> : ~/a/complete-rx
> : ~/a/outgoing
> : ~/a/complete-tx
> : ~/b
> : ~/b/incoming
> : ~/b/complete-rx
> : ~/b/outgoing
> : ~/b/complete-tx
> :
> : The .kermrc for the account had lines like:
> :
> : set receive move-to complete-rx
> : set send move-to complete-tx
> :
> : Under 8.206 we could change to directory "a" or directory "b" and issue
> : a send command like "send test.txt incoming/test.txt". The incomplete
> : file during transfer would sit in the appropriate incoming directory and
> : then would be moved to the approprate complete-rx directory on
> : completion. Under 8.209 the completed files sit in the incoming
> : directory unless we create a "complete-rx" directory in the home:
> :
> : ~/complete-rx
> :
> : and then they move there no matter which incoming directory they
> : arrived in.
> :
> I would venture to say that the behavior you were relying on was not
> intentional.  Although my notes don't show it, I suspect that somebody else
> -- maybe even me -- was surprised when a relative directory name was not
> resolved in the context in which the command was given, especially since
> after changing contexts it might not be be valid.
>
> : If this was for one or two sites we could work around it by creating
> : different accounts for each one, but this is for 1200+ sites and one
> : account makes it managable.
> :
> Well, when you put it that way I can see how deferred evaluation could be
> useful too, in a use-at-your-own-risk sort of way.  But this turns out to
> be a rather tricky question, since immediate and deferred evaluation can
> be applied independently to the context (current directory for relative
> filespecs) and to any variables in the MOVE-TO or RENAME-TO string, e.g.:
>
>   SET RECEIVE RENAME-TO \v(filename)_\v(ndate)_\v(ntime)_\v(userid)_\v(pid)
>
> Deferring evaluation of the MOVE/RENAME-TO string until it is used means
> that an error might not be detected until hours into the operation, after
> everybody has gone home.
>
> : If I could remotely set the send/receive move-to destinations, that
> : might work, too.
> :
> That would be a change too.  But clearly changes are necessary, especially
> since in researching this I discovered that the SET RECEIVE RENAME-TO
> example (which is taken from the C-Kermit 7.0 update notes) is broken too.
>
> My first reaction would be accept the MOVE-TO/RENAME-TO argument as-is
> at parse time, with no checking, and then evaluate it upon use.  This way,
> if you give an absolute pathname, it is constant; if you give a
> relative one, its resoluation varies with the context.  To extend same
> flexiblity to variables in the string, such as \v(time), we'd have to
> evaluate them at *parse* time.  If the user wanted to defer evaluation
> until use, s/he'd have to double the backslash.  A tad hard to explain,
> but it leaves the user with every combination of choices.  If I get a
> chance to work on the code again, I'll try this and see how it feels.
>
> In the meantime, I'd recommend you fall back to whatever version of
> C-Kermit you were using before.
>
> Thanks for the report.
>
> - Frank

--
----------------------------------------------------------------------
Derek Chen-Becker
Senior Network Engineer
CPI Corp, Inc.
1706 Washington Ave
St. Louis, MO 63103
Phone: [phone] x6014
Fax:   [phone]
[e-mail]
PGP Key available from public key servers
Fingerprint: 1C34 D81E D8A0 641D 6C8C  E952 3B15 693F 9184 BC58
----------------------------------------------------------------------